2.3. Changes need to iCalendar Products

If this legislation goes forward, the following changes will need to take place:

1. Any iCalendar product that currently uses timezone information will have to have their timezone ‘definitions’ updated to reflect the new start and end periods for DST. This affects both calendaring servers and clients, including desktop and mobile clients.

   • In the case of servers, this may be a simple process of upgrading timezone definitions.

   • In the case of clients, either an automated or manual upgrade of the timezone definitions will be required, subject to the other issues described below. This process will have to take place on ALL systems using iCalendar — potentially tens or hundreds of millions of users.

   • This change is not just limited to US systems — anyone outside the US that needs to do business with the US or travel to the US will need their definitions updated.

2. Given that the legislation proposes this change taking effect in March 2006, it is quite likely that there are already schedules of events defined for the period when DST is extended. The question arises as to how these existing events should be adjusted.

3. Typically there are two ways in which timezone definitions are enumerated.

   1. Using the naming scheme defined in the ‘Olsen’ timezone database (). This splits the timezone name into two parts: a region (typically a continent) and a city. For example: ‘America/New_York’, ‘America/Montreal’, ‘Europe/London’.

   2. Using the colloquial timezone name, e.g. ‘Eastern’, ‘Central’, ‘GMT’.

   For 3) a), updating timezone definitions is a matter of identifying which cities are in the US and changing just those definitions. If other countries (e.g. Canada) choose not to adopt the same changes, then the definitions for cities in Canada could remain the same. i.e. ‘America/New_York’ would be changed and ‘America/Montreal’ would be unchanged.

   For 3) b) the situation is more complex if other countries do not adopt the changes. In that case the existing definitions would need to be split into separate items to reflect the different timezone rules in each region — using Canada as an example again: ‘US-Eastern’ and ‘Canada-Eastern’. Any upgrade process to existing systems would have to determine whether an event that currently uses the ‘Eastern’ definition should be assigned ‘US-Eastern’ or ‘Canada-Eastern’. It may not be possible to automatically determine that in all cases and explicit human intervention may be required.

4. The Calendaring and Scheduling consortium recently carried out a survey on timezone support in calendar products. One conclusion from that is that a number of products convert local time information with a supplied timezone into UTC (the ‘standard’ time reference) as a simplification. As a result of this, timezone information is effectively lost. Such products will need to determine how to do any adjustment of the UTC times based on the proposed DST changes.